SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Authenticator</title>

</head>

Authenticator

</h1>

</header>

/* start https://en.wikipedia.org/ */

.mw-parser-output .hatnote{font-style:italic}.mw-parser-output div.hatnote{padding-left:1.6em;margin-bottom:0.5em}.mw-parser-output .hatnote i{font-style:normal}.mw-parser-output .hatnote+link+.hatnote{margin-top:-0.5em}@media print{body.ns-0 .mw-parser-output .hatnote{display:none!important}}

/* end https://en.wikipedia.org/ */

</style><div role="note" class="hatnote navigation-not-searchable">For the role of the authenticator in the 802.1X authentication protocol, see <a href="IEEE_802.1X" title="IEEE 802.1X">IEEE 802.1X</a>.</div>

An authenticator is a means used to confirm a user's identity,<a href="#cite_note-1">[1]</a><a href="#cite_note-2">[2]</a> that is, to perform digital authentication. A person authenticates to a computer system or application by demonstrating that he or she has possession and control of an authenticator.<a href="#cite_note-NIST-SP-800-63-3-3">[3]</a><a href="#cite_note-4">[4]</a> In the simplest case, the authenticator is a common <a href="Password" title="Password">password</a>.

Using the terminology of the NIST Digital Identity Guidelines,<a href="#cite_note-NIST-SP-800-63-3-3">[3]</a> the party to be authenticated is called the claimant while the party verifying the identity of the claimant is called the verifier. When the claimant successfully demonstrates possession and control of one or more authenticators to the verifier through an established authentication protocol, the verifier is able to infer the claimant's identity.

<div class="mw-heading mw-heading2"><h2 id="Classification">Classification</h2></div>

Authenticators may be characterized in terms of secrets, factors, and physical forms.

<div class="mw-heading mw-heading3"><h3 id="Authenticator_secrets">Authenticator secrets</h3></div>

Every authenticator is associated with at least one secret that the claimant uses to demonstrate possession and control of the authenticator. Since an attacker could use this secret to impersonate the user, an authenticator secret must be protected from theft or loss.

The type of secret is an important characteristic of the authenticator. There are three basic types of authenticator secret: a memorized secret and two types of cryptographic keys, either a symmetric key or a private key.

<div class="mw-heading mw-heading4"><h4 id="Memorized_secret">Memorized secret</h4></div>

A memorized secret is intended to be memorized by the user. A well-known example of a memorized secret is the common <a href="Password" title="Password">password</a>, also called a passcode, a <a href="Passphrase" title="Passphrase">passphrase</a>, or a <a href="Personal_identification_number" title="Personal identification number">personal identification number</a> (PIN).

An authenticator secret known to both the claimant and the verifier is called a <a href="Shared_secret" title="Shared secret">shared secret</a>. For example, a memorized secret may or may not be shared. A symmetric key is shared by definition. A private key is not shared.

An important type of secret that is both memorized and shared is the password. In the special case of a password, the authenticator is the secret.

<div class="mw-heading mw-heading4"><h4 id="Cryptographic_key">Cryptographic key</h4></div>

A cryptographic authenticator is one that uses a <a href="Key_(cryptography)" title="Key (cryptography)">cryptographic key</a>. Depending on the key material, a cryptographic authenticator may use <a href="Cryptography#Symmetric-key_cryptography" title="Cryptography">symmetric-key cryptography</a> or <a href="Cryptography#Public-key_cryptography" title="Cryptography">public-key cryptography</a>. Both avoid memorized secrets, and in the case of public-key cryptography, there are no <a href="Shared_secret" title="Shared secret">shared secrets</a> as well, which is an important distinction.

Examples of cryptographic authenticators include <a href="Initiative_for_Open_Authentication" title="Initiative for Open Authentication">OATH</a> authenticators and <a href="FIDO_Alliance" title="FIDO Alliance">FIDO</a> authenticators. The name OATH is an acronym from the words "Open AuTHentication" while FIDO stands for Fast IDentity Online. Both are the results of an industry-wide collaboration to develop an open <a href="Reference_architecture" title="Reference architecture">reference architecture</a> using open standards to promote the adoption of strong authentication.

By way of counterexample, a password authenticator is not a cryptographic authenticator. See the <a href="#Examples">#Examples</a> section for details.

<div class="mw-heading mw-heading5"><h5 id="Symmetric_key">Symmetric key</h5></div>

A symmetric key is a shared secret used to perform symmetric-key cryptography. The claimant stores their copy of the shared key in a dedicated hardware-based authenticator or a software-based authenticator implemented on a smartphone. The verifier holds a copy of the symmetric key.

<div class="mw-heading mw-heading5"><h5 id="Public-private_key_pair">Public-private key pair</h5></div>

A public-private key pair is used to perform public-key cryptography. The public key is known to (and trusted by) the verifier while the corresponding private key is bound securely to the authenticator. In the case of a dedicated hardware-based authenticator, the private key never leaves the confines of the authenticator.

<div class="mw-heading mw-heading3"><h3 id="Authenticator_factors_and_forms">Authenticator factors and forms</h3></div>

An authenticator is something unique or distinctive to a user (something that one has), is activated by either a <a href="Personal_identification_number" title="Personal identification number">PIN</a> (something that one knows), or is a <a href="Biometrics" title="Biometrics">biometric</a> ("something that is unique to oneself"). An authenticator that provides only one of these factors is called a single-factor authenticator whereas a multi-factor authenticator incorporates two or more factors. A multi-factor authenticator is one way to achieve <a href="Multi-factor_authentication" title="Multi-factor authentication">multi-factor authentication</a>. A combination of two or more single-factor authenticators is not a multi-factor authentication, yet may be suitable in certain conditions.

Authenticators may take a variety of physical forms (except for a memorized secret, which is intangible). One can, for example, hold an authenticator in one's hand or wear one on the face, wrist, or finger.<a href="#cite_note-5">[5]</a><a href="#cite_note-6">[6]</a><a href="#cite_note-7">[7]</a>

It is convenient to describe an authenticator in terms of its hardware and software components. An authenticator is hardware-based or software-based depending on whether the secret is stored in hardware or software, respectively.

An important type of hardware-based authenticator is called a security key,<a href="#cite_note-8">[8]</a> also called a <a href="Security_token" title="Security token">security token</a> (not to be confused with <a href="Access_token" title="Access token">access tokens</a>, <a href="Session_token" class="mw-redirect" title="Session token">session tokens</a>, or other types of security tokens). A security key stores its secret in hardware, which prevents the secret from being exported. A security key is also resistant to malware since the secret is at no time accessible to software running on the host machine.

A software-based authenticator (sometimes called a <a href="Software_token" title="Software token">software token</a>) may be implemented on a general-purpose electronic device such as a <a href="Laptop" title="Laptop">laptop</a>, a <a href="Tablet_computer" title="Tablet computer">tablet computer</a>, or a <a href="Smartphone" title="Smartphone">smartphone</a>. For example, a software-based authenticator implemented as a <a href="Mobile_app" title="Mobile app">mobile app</a> on the claimant's smartphone is a type of phone-based authenticator. To prevent access to the secret, a software-based authenticator may use a processor's <a href="Trusted_execution_environment" title="Trusted execution environment">trusted execution environment</a> or a <a href="Trusted_Platform_Module" title="Trusted Platform Module">Trusted Platform Module</a> (TPM) on the client device.

A platform authenticator is built into a particular client device platform, that is, it is implemented on device. In contrast, a roaming authenticator is a cross-platform authenticator that is implemented off device. A roaming authenticator connects to a device platform via a transport protocol such as <a href="USB" title="USB">USB</a>.

<div class="mw-heading mw-heading2"><h2 id="Examples">Examples</h2></div>

The following sections describe narrow classes of authenticators. For a more comprehensive classification, see the NIST Digital Identity Guidelines.<a href="#cite_note-NIST-SP-800-63B-9">[9]</a>

<div class="mw-heading mw-heading3"><h3 id="Single-factor_authenticators">Single-factor authenticators</h3></div>

To use an authenticator, the claimant must explicitly indicate their intent to authenticate. For example, each of the following gestures is sufficient to establish intent:

<ul><li>The claimant types a password into a password field, or</li>

<li>The claimant places their finger on a fingerprint reader, or</li>

<li>The claimant presses a button to indicate approval</li></ul>

The latter is called a test of user presence (TUP). To activate a single-factor authenticator (something that one has), the claimant may be required to perform a TUP, which avoids unintended operation of the authenticator.

A <a href="Password" title="Password">password</a> is a secret that is intended to be memorized by the claimant and shared with the verifier. Password authentication is the process whereby the claimant demonstrates knowledge of the password by transmitting it over the network to the verifier. If the transmitted password agrees with the previously shared secret, user authentication is successful.

One-time passwords (OTPs) have been used since the 1980s. In 2004, an Open Authentication Reference Architecture for the secure generation of OTPs was announced at the annual <a href="RSA_Conference" title="RSA Conference">RSA Conference</a>.<a href="#cite_note-10">[10]</a><a href="#cite_note-11">[11]</a> The <a href="Initiative_for_Open_Authentication" title="Initiative for Open Authentication">Initiative for Open Authentication</a> (OATH) launched a year later. Two IETF standards grew out of this work, the <a href="HMAC-based_One-time_Password_algorithm" class="mw-redirect" title="HMAC-based One-time Password algorithm">HMAC-based One-time Password (HOTP) algorithm</a> and the <a href="Time-based_One-time_Password_algorithm" class="mw-redirect" title="Time-based One-time Password algorithm">Time-based One-time Password (TOTP) algorithm</a> specified by RFC 4226 and RFC 6238, respectively. By OATH OTP, we mean either HOTP or TOTP. OATH certifies conformance with the HOTP and TOTP standards.<a href="#cite_note-OATH-cert-12">[12]</a>

A traditional password (something that one knows) is often combined with a one-time password (something that one has) to provide two-factor authentication.<a href="#cite_note-Hoffman-Andrews_and_Gebhart_2017-13">[13]</a> Both the password and the OTP are transmitted over the network to the verifier. If the password agrees with the previously shared secret, and the verifier can confirm the value of the OTP, user authentication is successful.

One-time passwords are generated on demand by a dedicated OATH OTP authenticator that encapsulates a secret that was previously shared with the verifier. Using the authenticator, the claimant generates an OTP using a cryptographic method. The verifier also generates an OTP using the same cryptographic method. If the two OTP values match, the verifier can conclude that the claimant possesses the shared secret.

A well-known example of an OATH authenticator is <a href="Google_Authenticator" title="Google Authenticator">Google Authenticator</a>,<a href="#cite_note-Google-Authenticator-14">[14]</a> a phone-based authenticator that implements both HOTP and TOTP.

<div class="mw-heading mw-heading4"><h4 id="Mobile_Push">Mobile Push</h4></div>

A mobile push authenticator is essentially a native app running on the claimant's mobile phone. The app uses public-key cryptography to respond to push notifications. In other words, a mobile push authenticator is a single-factor cryptographic software authenticator. A mobile push authenticator (something that one has) is usually combined with a password (something that one knows) to provide two-factor authentication. Unlike one-time passwords, mobile push does not require a shared secret beyond the password.

After the claimant authenticates with a password, the verifier makes an out-of-band authentication request to a <a href="Trusted_third_party" title="Trusted third party">trusted third party</a> that manages a public-key infrastructure on behalf of the verifier. The trusted third party sends a push notification to the claimant's mobile phone. The claimant demonstrates possession and control of the authenticator by pressing a button in the user interface, after which the authenticator responds with a digitally signed assertion. The trusted third party verifies the signature on the assertion and returns an authentication response to the verifier.

The proprietary mobile push authentication protocol runs on an out-of-band secondary channel, which provides flexible deployment options. Since the protocol requires an open network path to the claimant's mobile phone, if no such path is available (due to network issues, e.g.), the authentication process can not proceed.<a href="#cite_note-Hoffman-Andrews_and_Gebhart_2017-13">[13]</a>

A <a href="FIDO_Alliance" title="FIDO Alliance">FIDO</a> <a href="Universal_2nd_Factor" title="Universal 2nd Factor">Universal 2nd Factor</a> (U2F) authenticator (something that one has) is a single-factor cryptographic authenticator that is intended to be used in conjunction with an ordinary web password. Since the authenticator relies on public-key cryptography, U2F does not require an additional shared secret beyond the password.

To access a U2F authenticator, the claimant is required to perform a test of user presence (TUP), which helps prevent unauthorized access to the authenticator's functionality. In practice, a TUP consists of a simple button push.

A U2F authenticator interoperates with a conforming web <a href="User_agent" title="User agent">user agent</a> that implements the U2F JavaScript API.<a href="#cite_note-15">[15]</a> A U2F authenticator necessarily implements the CTAP1/U2F protocol, one of the two protocols specified in the FIDO <a href="Client_to_Authenticator_Protocol" title="Client to Authenticator Protocol">Client to Authenticator Protocol</a>.<a href="#cite_note-FIDO-CTAP-16">[16]</a>

Unlike mobile push authentication, the U2F authentication protocol runs entirely on the front channel. Two round trips are required. The first round trip is ordinary password authentication. After the claimant authenticates with a password, the verifier sends a challenge to a conforming browser, which communicates with the U2F authenticator via a custom JavaScript API. After the claimant performs the TUP, the authenticator signs the challenge and returns the signed assertion to the verifier via the browser.

<div class="mw-heading mw-heading3"><h3 id="Multi-factor_authenticators">Multi-factor authenticators</h3></div>

To use a multi-factor authenticator, the claimant performs full user verification. The multi-factor authenticator (something that one has) is activated by a <a href="Personal_identification_number" title="Personal identification number">PIN</a> (something that one knows), or a <a href="Biometrics" title="Biometrics">biometric</a> (something that is unique to oneself"; e.g. fingerprint, face or voice recognition), or some other verification technique.<a href="#cite_note-NIST-SP-800-63-3-3">[3]</a>

To withdraw cash from an <a href="Automated_teller_machine" class="mw-redirect" title="Automated teller machine">automated teller machine</a> (ATM), a bank customer inserts an ATM card into a cash machine and types a Personal Identification Number (PIN). The input PIN is compared to the PIN stored on the card's chip. If the two match, the ATM withdrawal can proceed.

Note that an ATM withdrawal involves a memorized secret (i.e., a PIN) but the true value of the secret is not known to the ATM in advance. The machine blindly passes the input PIN to the card, which compares the customer's input to the secret PIN stored on the card's chip. If the two match, the card reports success to the ATM and the transaction continues.

An ATM card is an example of a multi-factor authenticator. The card itself is something that one has while the PIN stored on the card's chip is presumably something that one knows. Presenting the card to the ATM and demonstrating knowledge of the PIN is a kind of multi-factor authentication.

<div class="mw-heading mw-heading4"><h4 id="Secure_Shell">Secure Shell</h4></div>

<a href="Secure_Shell" title="Secure Shell">Secure Shell</a> (SSH) is a client-server protocol that uses public-key cryptography to create a secure channel over the network. In contrast to a traditional password, an SSH key is a cryptographic authenticator. The primary authenticator secret is the SSH private key, which is used by the client to digitally sign a message. The corresponding public key is used by the server to verify the message signature, which confirms that the claimant has possession and control of the private key.

To avoid theft, the SSH private key (something that one has) may be encrypted using a <a href="Passphrase" title="Passphrase">passphrase</a> (something that one knows). To initiate a two-factor authentication process, the claimant supplies the passphrase to the client system.

Like a password, the SSH passphrase is a memorized secret but that is where the similarity ends. Whereas a password is a shared secret that is transmitted over the network, the SSH passphrase is not shared, and moreover, use of the passphrase is strictly confined to the client system. Authentication via SSH is an example of <a href="Passwordless_authentication" title="Passwordless authentication">passwordless authentication</a> since it avoids the transmission of a shared secret over the network. In fact, SSH authentication does not require a shared secret at all.

The FIDO U2F protocol standard became the starting point for the <a href="FIDO2_Project" class="mw-redirect" title="FIDO2 Project">FIDO2 Project</a>, a joint effort between the <a href="World_Wide_Web_Consortium" title="World Wide Web Consortium">World Wide Web Consortium</a> (W3C) and the FIDO Alliance. Project deliverables include the W3C Web Authentication (<a href="WebAuthn" title="WebAuthn">WebAuthn</a>) standard and the FIDO <a href="Client_to_Authenticator_Protocol" title="Client to Authenticator Protocol">Client to Authenticator Protocol</a> (CTAP).<a href="#cite_note-FIDO-FIDO2-17">[17]</a> Together WebAuthn and CTAP provide a strong authentication solution for the web.

A FIDO2 authenticator, also called a WebAuthn authenticator, uses public-key cryptography to interoperate with a WebAuthn client, that is, a conforming web <a href="User_agent" title="User agent">user agent</a> that implements the WebAuthn <a href="JavaScript" title="JavaScript">JavaScript</a> API.<a href="#cite_note-W3C-WebAuthn-18">[18]</a> The authenticator may be a platform authenticator, a roaming authenticator, or some combination of the two. For example, a FIDO2 authenticator that implements the CTAP2 protocol<a href="#cite_note-FIDO-CTAP-16">[16]</a> is a roaming authenticator that communicates with a WebAuthn client via one or more of the following transport options: <a href="USB" title="USB">USB</a>, <a href="Near-field_communication" title="Near-field communication">near-field communication</a> (NFC), or <a href="Bluetooth_Low_Energy" title="Bluetooth Low Energy">Bluetooth Low Energy</a> (BLE). Concrete examples of FIDO2 platform authenticators include Windows Hello<a href="#cite_note-19">[19]</a> and the <a href="Android_operating_system" class="mw-redirect" title="Android operating system">Android operating system</a>.<a href="#cite_note-20">[20]</a>

A FIDO2 authenticator may be used in either single-factor mode or multi-factor mode. In single-factor mode, the authenticator is activated by a simple test of user presence (e.g., a button push). In multi-factor mode, the authenticator (something that one has) is activated by either a <a href="Personal_identification_number" title="Personal identification number">PIN</a> (something that one knows) or a <a href="Biometrics" title="Biometrics">biometric</a> ("something that is unique to oneself").

<div class="mw-heading mw-heading2"><h2 id="Security_code">Security code</h2></div>

First and foremost, strong authentication begins with <a href="Multi-factor_authentication" title="Multi-factor authentication">multi-factor authentication</a>. The best thing one can do to protect a personal online account is to enable multi-factor authentication.<a href="#cite_note-Hoffman-Andrews_and_Gebhart_2017-13">[13]</a><a href="#cite_note-NCSC_2FA-21">[21]</a> There are two ways to achieve multi-factor authentication:

<ol><li>Use a multi-factor authenticator</li>

<li>Use a combination of two or more single-factor authenticators</li></ol>

In practice, a common approach is to combine a password authenticator (something that one knows) with some other authenticator (something that one has) such as a cryptographic authenticator.

Generally speaking, a <a href="#Cryptographic_key">cryptographic authenticator</a> is preferred over an authenticator that does not use cryptographic methods. All else being equal, a cryptographic authenticator that uses public-key cryptography is better than one that uses symmetric-key cryptography since the latter requires shared keys (which may be stolen or misused).

Again all else being equal, a hardware-based authenticator is better than a software-based authenticator since the authenticator secret is presumably better protected in hardware. This preference is reflected in the NIST requirements outlined in the next section.

<div class="mw-heading mw-heading3"><h3 id="NIST_authenticator_assurance_levels">NIST authenticator assurance levels</h3></div>

NIST defines three levels of assurance with respect to authenticators. The highest authenticator assurance level (AAL3) requires multi-factor authentication using either a multi-factor authenticator or an appropriate combination of single-factor authenticators. At AAL3, at least one of the authenticators must be a cryptographic hardware-based authenticator. Given these basic requirements, possible authenticator combinations used at AAL3 include:

<ol><li>A multi-factor cryptographic hardware-based authenticator</li>

<li>A single-factor cryptographic hardware-based authenticator used in conjunction with some other authenticator (such as a password authenticator)</li></ol>

See the NIST Digital Identity Guidelines for further discussion of authenticator assurance levels.<a href="#cite_note-NIST-SP-800-63B-9">[9]</a>

<div class="mw-heading mw-heading3"><h3 id="Restricted_authenticators">Restricted authenticators</h3></div>

Like authenticator assurance levels, the notion of a restricted authenticator is a NIST concept.<a href="#cite_note-NIST-SP-800-63-3-3">[3]</a> The term refers to an authenticator with a demonstrated inability to resist attacks, which puts the reliability of the authenticator in doubt. Federal agencies mitigate the use a restricted authenticator by offering subscribers an alternative authenticator that is not restricted and by developing a migration plan in the event that a restricted authenticator is prohibited from use at some point in the future.

Currently, the use of the <a href="Public_switched_telephone_network" title="Public switched telephone network">public switched telephone network</a> is restricted by NIST. In particular, the out-of-band transmission of one-time passwords (OTPs) via recorded voice messages or <a href="SMS" title="SMS">SMS</a> messages is restricted. Moreover, if an agency chooses to use voice- or SMS-based OTPs, that agency must verify that the OTP is being transmitted to a phone and not an IP address since <a href="Voice_over_IP" title="Voice over IP">Voice over IP</a> (VoIP) accounts are not routinely protected with multi-factor authentication.<a href="#cite_note-NIST-SP-800-63B-9">[9]</a>

<div class="mw-heading mw-heading2"><h2 id="Comparison">Comparison</h2></div>

It is convenient to use passwords as a basis for comparison since it is widely understood how to use a password.<a href="#cite_note-22">[22]</a> On computer systems, passwords have been used since at least the early 1960s.<a href="#cite_note-McMillan_2012-23">[23]</a><a href="#cite_note-Hunt_2017-24">[24]</a> More generally, passwords have been used since ancient times.<a href="#cite_note-25">[25]</a>

In 2012, Bonneau et al. evaluated two decades of proposals to replace passwords by systematically comparing web passwords to 35 competing authentication schemes in terms of their usability, deployability, and security.<a href="#cite_note-26">[26]</a> (The cited technical report is an extended version of the peer-reviewed paper by the same name.<a href="#cite_note-27">[27]</a>) They found that most schemes do better than passwords on security while every scheme does worse than passwords on deployability. In terms of usability, some schemes do better and some schemes do worse than passwords.

Google used the evaluation framework of Bonneau et al. to compare security keys to passwords and one-time passwords.<a href="#cite_note-28">[28]</a> They concluded that security keys are more usable and deployable than one-time passwords, and more secure than both passwords and one-time passwords.

<ul><li><a href="Electronic_authentication" title="Electronic authentication">Electronic authentication</a></li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist">

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://www.dni.gov/files/NCSC/documents/nittf/CNSSI-4009_National_Information_Assurance.pdf">"National Information Assurance (IA) Glossary"</a> (PDF). <a href="Committee_on_National_Security_Systems" title="Committee on National Security Systems">Committee on National Security Systems</a>. 26 April 2010. <a rel="nofollow" class="external text" href="https://ghostarchive.org/archive/20221009/https://www.dni.gov/files/NCSC/documents/nittf/CNSSI-4009_National_Information_Assurance.pdf">Archived</a> (PDF) from the original on 2022-10-09. Retrieved 31 March 2019.</cite>

</li>

<li id="cite_note-2"><a href="#cite_ref-2">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://www.its.bldrdoc.gov/fs-1037/fs-1037c.htm">"Glossary of Telecommunication Terms"</a>. <a href="Institute_for_Telecommunication_Sciences" title="Institute for Telecommunication Sciences">Institute for Telecommunication Sciences</a>. 7 August 1996. Retrieved 31 March 2019.</cite>

</li>

<li id="cite_note-NIST-SP-800-63-3-3">^ <a href="#cite_ref-NIST-SP-800-63-3_3-0">a</a> <a href="#cite_ref-NIST-SP-800-63-3_3-1">b</a> <a href="#cite_ref-NIST-SP-800-63-3_3-2">c</a> <a href="#cite_ref-NIST-SP-800-63-3_3-3">d</a> <cite id="CITEREFGrassiGarciaFenton2017" class="citation journal cs1">Grassi, Paul A.; Garcia, Michael E.; Fenton, James L. (June 2017). <a rel="nofollow" class="external text" href="https://pages.nist.gov/800-63-3/sp800-63-3.html">"NIST Special Publication 800-63-3: Digital Identity Guidelines"</a>. <a href="National_Institute_of_Standards_and_Technology" title="National Institute of Standards and Technology">National Institute of Standards and Technology</a> (NIST). <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.6028%2FNIST.SP.800-63-3">10.6028/NIST.SP.800-63-3</a>. Retrieved 5 February 2019.</cite> <code class="cs1-code">{{cite journal}}</code>: Cite journal requires <code class="cs1-code">|journal=</code> (help)

</li>

<li id="cite_note-4"><a href="#cite_ref-4">^</a> <cite id="CITEREFLindemann2017" class="citation web cs1">Lindemann, Rolf, ed. (11 April 2017). <a rel="nofollow" class="external text" href="https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-glossary-v1.2-ps-20170411.html">"FIDO Technical Glossary"</a>. <a href="FIDO_Alliance" title="FIDO Alliance">FIDO Alliance</a>. Retrieved 26 March 2019.</cite>

</li>

<li id="cite_note-5"><a href="#cite_ref-5">^</a> <cite id="CITEREFBianchiOakley2016" class="citation journal cs1">Bianchi, Andrea; Oakley, Ian (2016). <a rel="nofollow" class="external text" href="http://alsoplantsfly.com/files/2016/Bianchi_WearableAuthentication_itit16.pdf">"Wearable authentication: Trends and opportunities"</a> (PDF). It - Information Technology. 58 (5): 255–262. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1515%2Fitit-2016-0010">10.1515/itit-2016-0010</a>. <a href="S2CID_(identifier)" class="mw-redirect" title="S2CID (identifier)">S2CID</a> <a rel="nofollow" class="external text" href="https://api.semanticscholar.org/CorpusID:12772550">12772550</a>. <a rel="nofollow" class="external text" href="https://ghostarchive.org/archive/20221009/http://alsoplantsfly.com/files/2016/Bianchi_WearableAuthentication_itit16.pdf">Archived</a> (PDF) from the original on 2022-10-09.</cite>

</li>

<li id="cite_note-6"><a href="#cite_ref-6">^</a> <cite id="CITEREFStein2018" class="citation web cs1">Stein, Scott (26 July 2018). <a rel="nofollow" class="external text" href="https://www.cnet.com/news/why-cant-wear-os-smartwatches-be-security-keys-too/">"Why can't Wear OS smartwatches be security keys too?"</a>. CNET. Retrieved 31 March 2019.</cite>

</li>

<li id="cite_note-7"><a href="#cite_ref-7">^</a> <cite id="CITEREFWilliams2017" class="citation web cs1">Williams, Brett (27 June 2017). <a rel="nofollow" class="external text" href="https://mashable.com/2017/06/27/token-wearable-ring-authenticator/">"This smart ring gives you instant mobile payments with beefed up security"</a>. Mashable. Retrieved 31 March 2019.</cite>

</li>

<li id="cite_note-8"><a href="#cite_ref-8">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://fidoalliance.org/case-study-series-google-security-keys-work/">"Case Study: Google Security Keys Work"</a>. <a href="FIDO_Alliance" title="FIDO Alliance">FIDO Alliance</a>. 7 December 2016. Retrieved 26 March 2019.</cite>

</li>

<li id="cite_note-NIST-SP-800-63B-9">^ <a href="#cite_ref-NIST-SP-800-63B_9-0">a</a> <a href="#cite_ref-NIST-SP-800-63B_9-1">b</a> <a href="#cite_ref-NIST-SP-800-63B_9-2">c</a> <cite id="CITEREFGrassiFentonNewtonPerlner2017" class="citation journal cs1">Grassi, Paul A.; Fenton, James L.; Newton, Elaine M.; Perlner, Ray A.; Regenscheid, Andrew R.; Burr, William E.; Richer, Justin P. (2017). <a rel="nofollow" class="external text" href="https://pages.nist.gov/800-63-3/sp800-63b.html">"NIST Special Publication 800-63B: Digital Identity Guidelines: Authentication and Lifecycle Management"</a>. <a href="National_Institute_of_Standards_and_Technology" title="National Institute of Standards and Technology">National Institute of Standards and Technology</a> (NIST). <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.6028%2FNIST.SP.800-63b">10.6028/NIST.SP.800-63b</a>. Retrieved 5 February 2019.</cite> <code class="cs1-code">{{cite journal}}</code>: Cite journal requires <code class="cs1-code">|journal=</code> (help)

</li>

<li id="cite_note-10"><a href="#cite_ref-10">^</a> <cite id="CITEREFKucan2004" class="citation web cs1">Kucan, Berislav (24 February 2004). <a rel="nofollow" class="external text" href="https://www.helpnetsecurity.com/2004/02/24/open-authentication-reference-architecture-announced/">"Open Authentication Reference Architecture Announced"</a>. Help Net Security. Retrieved 26 March 2019.</cite>

</li>

<li id="cite_note-11"><a href="#cite_ref-11">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://openauthentication.org/specifications-technical-resources/">"OATH Specifications and Technical Resources"</a>. <a href="Initiative_for_Open_Authentication" title="Initiative for Open Authentication">Initiative for Open Authentication</a>. Retrieved 26 March 2019.</cite>

</li>

<li id="cite_note-OATH-cert-12"><a href="#cite_ref-OATH-cert_12-0">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://openauthentication.org/oath-certification/">"OATH Certification"</a>. The <a href="Initiative_for_Open_Authentication" title="Initiative for Open Authentication">Initiative for Open Authentication</a> (OATH). Retrieved 3 February 2019.</cite>

</li>

<li id="cite_note-Hoffman-Andrews_and_Gebhart_2017-13">^ <a href="#cite_ref-Hoffman-Andrews_and_Gebhart_2017_13-0">a</a> <a href="#cite_ref-Hoffman-Andrews_and_Gebhart_2017_13-1">b</a> <a href="#cite_ref-Hoffman-Andrews_and_Gebhart_2017_13-2">c</a> <cite id="CITEREFHoffman-AndrewsGebhart2017" class="citation web cs1">Hoffman-Andrews, Jacob; Gebhart, Gennie (22 September 2017). <a rel="nofollow" class="external text" href="https://www.eff.org/deeplinks/2017/09/guide-common-types-two-factor-authentication-web">"A Guide to Common Types of Two-Factor Authentication on the Web"</a>. <a href="Electronic_Frontier_Foundation" title="Electronic Frontier Foundation">Electronic Frontier Foundation</a>. Retrieved 26 March 2019.</cite>

</li>

<li id="cite_note-Google-Authenticator-14"><a href="#cite_ref-Google-Authenticator_14-0">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://github.com/google/google-authenticator/wiki">"Google Authenticator"</a>. <a href="GitHub" title="GitHub">GitHub</a>. Retrieved 3 February 2019.</cite>

</li>

<li id="cite_note-15"><a href="#cite_ref-15">^</a> <cite id="CITEREFBalfanzBirgissonLang2017" class="citation web cs1">Balfanz, Dirk; Birgisson, Arnar; Lang, Juan, eds. (11 April 2017). <a rel="nofollow" class="external text" href="https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-javascript-api-v1.2-ps-20170411.html">"FIDO U2F JavaScript API"</a>. <a href="FIDO_Alliance" title="FIDO Alliance">FIDO Alliance</a>. Retrieved 22 March 2019.</cite>

</li>

<li id="cite_note-FIDO-CTAP-16">^ <a href="#cite_ref-FIDO-CTAP_16-0">a</a> <a href="#cite_ref-FIDO-CTAP_16-1">b</a> <cite id="CITEREFBrandCzeskisEhrensvärdJones2019" class="citation web cs1">Brand, Christiaan; Czeskis, Alexei; Ehrensvärd, Jakob; Jones, Michael B.; Kumar, Akshay; Lindemann, Rolf; Powers, Adam; Verrept, Johan, eds. (30 January 2019). <a rel="nofollow" class="external text" href="https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html">"Client to Authenticator Protocol (CTAP)"</a>. <a href="FIDO_Alliance" title="FIDO Alliance">FIDO Alliance</a>. Retrieved 22 March 2019.</cite>

</li>

<li id="cite_note-FIDO-FIDO2-17"><a href="#cite_ref-FIDO-FIDO2_17-0">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://fidoalliance.org/fido2/">"FIDO2: Moving the World Beyond Passwords"</a>. FIDO Alliance. Retrieved 30 January 2019.</cite>

</li>

<li id="cite_note-W3C-WebAuthn-18"><a href="#cite_ref-W3C-WebAuthn_18-0">^</a> <cite id="CITEREFBalfanzCzeskisHodgesJones" class="citation web cs1">Balfanz, Dirk; Czeskis, Alexei; Hodges, Jeff; Jones, J.C.; Jones, Michael B.; Kumar, Akshay; Liao, Angelo; Lindemann, Rolf; Lundberg, Emil (eds.). <a rel="nofollow" class="external text" href="https://www.w3.org/TR/webauthn/">"Web Authentication: An API for accessing Public Key Credentials Level 1"</a>. World Wide Web Consortium (W3C). Retrieved 30 January 2019.</cite>

</li>

<li id="cite_note-19"><a href="#cite_ref-19">^</a> <cite id="CITEREFSimons2018" class="citation web cs1">Simons, Alex (November 20, 2018). <a rel="nofollow" class="external text" href="https://www.microsoft.com/en-us/microsoft-365/blog/2018/11/20/sign-in-to-your-microsoft-account-without-a-password-using-windows-hello-or-a-security-key/">"Secure password-less sign-in for your Microsoft account using a security key or Windows Hello"</a>. <a href="Microsoft" title="Microsoft">Microsoft</a>. Retrieved 6 March 2019.</cite>

</li>

<li id="cite_note-20"><a href="#cite_ref-20">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://fidoalliance.org/android-now-fido2-certified-accelerating-global-migration-beyond-passwords/">"Android Now FIDO2 Certified, Accelerating Global Migration Beyond Passwords"</a>. BARCELONA: <a href="FIDO_Alliance" title="FIDO Alliance">FIDO Alliance</a>. February 25, 2019. Retrieved 6 March 2019.</cite>

</li>

<li id="cite_note-NCSC_2FA-21"><a href="#cite_ref-NCSC_2FA_21-0">^</a> <cite class="citation web cs1"><a rel="nofollow" class="external text" href="https://www.ncsc.gov.uk/blog-post/two-factor-authentication-2fa-new-guidance-ncsc">"Two-factor authentication (2FA); new guidance from the NCSC"</a>. <a href="National_Cyber_Security_Centre_(United_Kingdom)" title="National Cyber Security Centre (United Kingdom)">National Cyber Security Centre</a> (NCSC). 8 Aug 2018.</cite>

</li>

<li id="cite_note-22"><a href="#cite_ref-22">^</a> <cite id="CITEREFHunt2018" class="citation web cs1">Hunt, Troy (5 November 2018). <a rel="nofollow" class="external text" href="https://www.troyhunt.com/heres-why-insert-thing-here-is-not-a-password-killer/">"Here's Why [Insert Thing Here] Is Not a Password Killer"</a>. Retrieved 24 March 2019.</cite>

</li>

<li id="cite_note-McMillan_2012-23"><a href="#cite_ref-McMillan_2012_23-0">^</a> <cite id="CITEREFMcMillan2012" class="citation magazine cs1">McMillan, Robert (27 January 2012). <a rel="nofollow" class="external text" href="https://www.wired.com/2012/01/computer-password/">"The World's First Computer Password? It Was Useless Too"</a>. <a href="Wired_magazine" class="mw-redirect" title="Wired magazine">Wired magazine</a>. Retrieved 22 March 2019.</cite>

</li>

<li id="cite_note-Hunt_2017-24"><a href="#cite_ref-Hunt_2017_24-0">^</a> <cite id="CITEREFHunt2017" class="citation web cs1">Hunt, Troy (26 July 2017). <a rel="nofollow" class="external text" href="https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/">"Passwords Evolved: Authentication Guidance for the Modern Era"</a>. Retrieved 22 March 2019.</cite>

</li>

<li id="cite_note-25"><a href="#cite_ref-25">^</a> <cite id="CITEREFMalempatiMogalla2011" class="citation journal cs1">Malempati, Sreelatha; Mogalla, Shashi (2011-07-31). <a rel="nofollow" class="external text" href="http://www.airccse.org/journal/nsa/0711ijnsa14.pdf">"An Ancient Indian Board Game as a Tool for Authentication"</a> (PDF). International Journal of Network Security & Its Applications. 3 (4): 154–163. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.5121%2Fijnsa.2011.3414">10.5121/ijnsa.2011.3414</a>.</cite>

</li>

<li id="cite_note-26"><a href="#cite_ref-26">^</a> <cite id="CITEREFBonneauHerleyOorschotStajano2012" class="citation journal cs1">Bonneau, Joseph; Herley, Cormac; Oorschot, Paul C. van; Stajano, Frank (2012). <a rel="nofollow" class="external text" href="https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-817.html">"The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes"</a>. Technical Report - University of Cambridge. Computer Laboratory. Cambridge, UK: University of Cambridge Computer Laboratory. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.48456%2Ftr-817">10.48456/tr-817</a>. <a href="ISSN_(identifier)" class="mw-redirect" title="ISSN (identifier)">ISSN</a> <a rel="nofollow" class="external text" href="https://search.worldcat.org/issn/1476-2986">1476-2986</a>. Retrieved 22 March 2019.</cite>

</li>

<li id="cite_note-27"><a href="#cite_ref-27">^</a> <cite id="CITEREFBonneauHerleyOorschotStajano2012" class="citation conference cs1">Bonneau, Joseph; Herley, Cormac; Oorschot, Paul C. van; Stajano, Frank (2012). The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes. 2012 IEEE Symposium on Security and Privacy. San Francisco, CA. pp. 553–567. <a href="CiteSeerX_(identifier)" class="mw-redirect" title="CiteSeerX (identifier)">CiteSeerX</a> <a rel="nofollow" class="external text" href="https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.473.2241">10.1.1.473.2241</a>. <a href="Doi_(identifier)" class="mw-redirect" title="Doi (identifier)">doi</a>:<a rel="nofollow" class="external text" href="https://doi.org/10.1109%2FSP.2012.44">10.1109/SP.2012.44</a>.</cite>

</li>

<li id="cite_note-28"><a href="#cite_ref-28">^</a> <cite id="CITEREFLangCzeskisBalfanzSchilder2016" class="citation web cs1">Lang, Juan; Czeskis, Alexei; Balfanz, Dirk; Schilder, Marius; Srinivas, Sampath (2016). <a rel="nofollow" class="external text" href="http://fc16.ifca.ai/preproceedings/25_Lang.pdf">"Security Keys: Practical Cryptographic Second Factors for the Modern Web"</a> (PDF). Financial Cryptography and Data Security 2016. <a rel="nofollow" class="external text" href="https://ghostarchive.org/archive/20221009/http://fc16.ifca.ai/preproceedings/25_Lang.pdf">Archived</a> (PDF) from the original on 2022-10-09. Retrieved 26 March 2019.</cite>

</li>

</ol></div></div></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2025-07-30" href="https://en.wikipedia.org/wiki/?title=Authenticator&oldid=1303409173">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>